Ask a controls engineer to draw the ISA-95 equipment hierarchy — enterprise, site, area, work center, work unit — and they’ll sketch it from memory. It’s the first thing every MES vendor trains on, and for good reason: if you can’t model your plant’s physical and organizational structure correctly, nothing built on top of it will make sense. But ask that same engineer to open the actual XML payload their middleware sends to SAP or Oracle every time a work order closes, and you’ll usually get silence. That’s the gap. Plants have gotten very good at the hierarchy and never learned the language spoken across it.
That language is B2MML — Business To Manufacturing Markup Language. It’s the XML implementation of the ISA-95 data model, maintained by the Manufacturing Enterprise Solutions Association (MESA International), and it’s what actually moves data between your MES and your ERP. The hierarchy tells you what things are called and how they nest. B2MML tells you what a message looks like when Level 3 (MES) hands something to Level 4 (ERP), or vice versa. Most integration failures — the ones that surface eighteen months later during an ERP upgrade — trace back to nobody ever inspecting that message contract in the first place.
Why the hierarchy is the easy part
ISA-95 Part 1 defines the models: equipment hierarchy, personnel, material, process segments. ISA-95 Part 2 defines the object attributes. This is static structure, and structure is forgiving. If you mislabel a work center as a work unit, it’s annoying but rarely catastrophic — someone notices during commissioning and fixes the mapping.
ISA-95 Part 5, on the other hand, defines transactions — B2MML schemas for things like Production Schedule, Production Performance, and Material/Personnel/Equipment actuals. These aren’t static objects. They’re message exchanges with a shape, a cardinality, and an implicit contract about what fields are mandatory, what’s optional, and what happens when a field is empty versus absent. This is where integrations actually live or die, because a transaction contract has to survive change — new ERP versions, new MES modules, new plant configurations — and static structure doesn’t have to.
The three transaction sets that matter most
If you’re integrating MES and ERP at Level 3/Level 4, three B2MML transaction sets do almost all the work. Understanding what each one actually carries — and where teams get sloppy — is the practical core of this whole exercise.
Production Schedule (ERP to MES)
This is the work order, the “what to make, how much, by when.” In B2MML terms it’s built from ProductionSchedule containing one or more ProductionRequest elements, each referencing a segment, a quantity, and a material definition. The common failure: ERPs change how they represent partial lots, co-products, or schedule revisions between versions, and MES middleware that hard-coded assumptions about a single ProductionRequest per order breaks silently when the new ERP release starts sending revised or split requests. The contract needs to explicitly state cardinality — how many requests per schedule, how revisions are flagged, whether a resent schedule replaces or appends.
Production Performance (MES to ERP)
This is the report-back: what actually got made, when, on what equipment, by whom, against which schedule. It’s built from ProductionPerformance and ProductionResponse elements and typically carries the actual-to-planned linkage that finance and planning depend on for variance reporting. This is the transaction set most likely to be quietly non-conformant, because MES vendors often build their own internal “performance” object first and bolt on a B2MML export later, sometimes losing traceability back to the original schedule ID in the process. If your ERP can’t tie a performance record back to the exact schedule request it fulfilled, your variance reports are guessing.
Material Consumption / Genealogy
This one carries lot and material actuals — what was consumed, from which lot, at what quantity — using MaterialActualUsage or similar structures. It’s the transaction set most exposed to regulatory and traceability risk, particularly in food, pharma, and anything with recall exposure. It’s also the one most likely to get customized beyond recognition, because every plant’s material master and lot-numbering convention is a little different, and every customization is a place where a schema validator would fail if anyone bothered to run one.
Why this breaks specifically at renewal time
Here’s the mechanism worth understanding: most MES-to-ERP integrations aren’t built against the B2MML schema directly. They’re built against whatever the middleware platform’s connector currently emits — a point-in-time snapshot that happens to satisfy the ERP version installed at go-live. Nobody validates that output against the actual ISA-95 Part 5 XSD, because it works, and “it works” is where projects stop looking. Then the ERP gets upgraded, or the middleware gets upgraded, or the MES gets replaced, and the new version’s connector generates output that’s still nominally B2MML but shaped slightly differently — different optional-field handling, different namespace versions, different assumptions about repeating elements. The integration doesn’t fail loudly. It fails quietly, dropping fields or mis-mapping quantities, and someone in planning eventually notices the numbers don’t reconcile.
This is exactly the situation a lot of plants are walking into now. Vendor moves — SAP integrating generative AI capabilities into its manufacturing execution offering, Rockwell aligning its industrial software stack more closely with Plex — are prompting a wave of MES-ERP contract renewals across the industry. Every one of those renewals is an opportunity to either re-platform the same undocumented, custom-shaped integration, or actually specify the transaction contract this time.
What “actually specify it” looks like
Concretely, this means producing an integration specification, separate from any vendor’s default connector documentation, that states for each transaction set: which B2MML elements are used, which are mandatory versus optional in your plant’s context, how revisions and cancellations are represented, how errors and rejections are communicated back, and what the versioning strategy is when either side upgrades. Validate sample messages against the published B2MML XSDs — MESA publishes these — rather than trusting that “the connector says it’s compliant.” Keep that specification under change control, the same way you’d version-control a PLC program, so that when the ERP vendor pushes a new release, someone can diff the new message shape against the documented contract before it goes to production.
None of this is exotic. It’s the same discipline plants already apply to physical interlocks and safety logic, applied to a data contract instead of a relay. The equipment hierarchy told you what to call things. The transaction contract is what keeps them talking to each other after the next upgrade — and it’s the part almost nobody has actually read.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
